The present invention is related to recovery of database objects in a computer system, and in particular, to an in use manager for tracking use of database objects to ensure quick recovery of the objects following abnormal system termination.
In a database system, recovery processing is normally required after an abnormal system termination in order to ensure that the integrity of the data within the database is preserved. Typically, database objects that were "in-use" at the time of the termination may need selective recovery actions performed. Objects are files of stored information, and usually include header data that describes the stored information. The header can also contain security information.
Information about which objects are in use is sometimes maintained in a central repository to guarantee that all objects are properly recovered if the system terminates abnormally. The central repository is commonly referred to as an in-use table. The table is used to identify the objects which were being used, and to limit recovery actions to those objects. It is desirable that the table be of modest size, be trustworthy following a crash, and not be a significant source of contention.
It would be possible to keep the information about which objects are in use directly within each object itself, but this is undesirable, because it would require that each and every object be paged into main memory from secondary storage and examined at system restart. This consumes too much time. Another possibility would be to record in-use status in an object directory. This is also impractical because there can be many directories within the system to search, and not all objects may be required to be in a directory (this is true on the IBM Application System/400 (TM)--some objects which require recovery are not stored in directories). In addition, many computer systems house a large quantity of rather dormant objects which are rarely used. It would be inefficient to exhaustively examine all such objects in the face of a crash in order to determine whether these objects require recovery processing. Instead, it is desirable to provide a mechanism which minimizes the number of objects which must be searched for potential recovery processing.
In the IBM System/38, an in use table consisted of a number of entries. Each entry corresponded to an object. The table itself was an object, and could be locked by a single process. This would serialize operations performed against the table, causing it to be a major bottleneck in the system. It was particularly true when objects were repetitively put in use and taken out of use at a high rate. The table was also searched in a linear manner. With a large table, the linear search was not efficient. The table was written to disk each time the table was modified. This resulted in a high rate of traffic on the input/output lines. These synchronous write operations were a major system bottleneck during high I/0 traffic times. One further limitation of the table was that it only indicated if an object was in use. An object which is merely being read should not need to be recovered, since no changes were made.